The present invention relates to automated engineering management systems in general and more particularly to a method and system for establishing version control of engineering changes in order to keep track of all data pertaining to engineering changes.
Most manufactured products pass through a period of development during which the design data is very volatile. During this period, alternative designs for assembly items and their component items may be under consideration simultaneously. Each such alternative design may be stored in the data base as an independent version or iteration of the item before a selected design is authorized to be released via an engineering change notice (EC). This is an example of a non-engineering change controlled item which needs to have multiple versions.
An engineering change is used to package designs or design modifications that are related as, for example, all modifications to an original design necessary to improve the design. A single engineering change may affect different pieces of data on different items. It can result in the addition of one or more bill of material components on one part and create item data for the component item. It can also change a drawing reference on another part.
Once a design is selected, and an engineering change authorizes a new item to be released to manufacturing, the item is said to be under engineering change control. Subsequent changes to the same item are authorized by new engineering changes. Version control methods are used to maintain a history of all engineering changes. The types of engineering change data that need version control include item engineering data, components in bills of material, optional components, local substitute components, item responsibility data, sources of supply, reference documents, manufacturing lead time and yield, routing and operation, notes and comments. Engineering change data is further classified by its status such as pre-release, release, accepted by manufacturing and currently effective status. In pre-release status, design engineering data is being defined and reviewed by the design group. Release status indicates that a formalized engineering design has been released to manufacturing by the design group. Accept status is obtained when the released data has been reviewed by the manufacturing engineer or manager. At this stage in the design life cycle, additional manufacturing data can be added to the released data. Effective status is achieved when the released data is ready to be incorporated into production.
There are several known ways of storing the historical sequence of changes to data elements. The most detailed method treats every data element independently and stores both "before" and "after" images of every data element that has been changed. Several data base management systems use this approach for data base recovery purposes. It optimizes data storage but is inefficient for data processing. An opposing method includes all version controlled data elements in a single large object. Thus a change to any data element requires "before" and "after" images of the entire object. This second approach makes the processing logic very complex and wastes large amounts of storage space unless the types of data and the number of data elements in the object are limited to a manageable number.
Having adopted this second approach, commercially available products for version control for tracking engineering changes have been limited to bills of material (BOM) in released status only. Engineering change data in pre-release status, if any, are kept in a duplicate file or data base table so that the same computer program can be used for both. The most common version control technique used is known as date effectivity in which a range of effective dates is specified during which a released bill of material component can be used in an assembly. This information is stored in the computer system as an occurrence or instance of a specific bill of material component object. The ranges of effective dates are stored as attributes of the bill of material component object. These dates are then used for the selection of a specific occurrence or version of a bill of material component. Overlapped ranges of effective dates for different versions of the same component are not permitted. References to the engineering changes which added and removed the bill of material components are included as optional attributes and are not used for version control. No distinction is made between non-engineering change controlled and engineering change controlled versions of items or between pre-release and released versions of items and bill of material components.
A typical implementation of pre-release data for bill of material components is the use of a separate data base or file to contain the pre-release data which avoids the need to implement additional version control techniques. This is an inefficient implementation since at the time of engineering change release the pre-release data must be copied over to the data base or file containing the released data.
Traditionally, most commercially available software products were developed using date effectivity for version control of bills of material. Examples are IBM Corporation's COPICS (Communications Oriented Production Information and Control System) and MAPICS (Manufacturing Accounting and Production Information Control System) families of products. More recently, some of the commercially available products have been modified to handle serial number effectivity in order to track "as built" product configurations to satisfy statutory accounting requirements. An example of such product is IBM Corporation's "COPICS Defense" product. Such modified software products replace a range of effective dates by a range of serial numbers for version control. These version control techniques are limited to released versions of bill of material components only. Version control of other item related and bill of material related data and having a status other than release has not been implemented.